Policy management is a multi-step process. For example, the process for management of a security policy involves defining, review, validating, verifying, approving, modifying, retrieving, removing, and enforcing security policies. Not only that, a security policy has many components and points of enforcement because a company's security policies are generally tied to the company's specific business requirements and policies. One component of a desirable security policy solution concerns assisting IT personnel in their efforts to define security policies in computing environments in a cost-effective and intuitive manner. The company's security policies are generally in written form in electronic or paper documents, and the IT personnel would need to map these written descriptions into a form compatible with the computing environment.
For example, IT personnel may wish to extract a set of security policies from a human-readable document that may be directly or indirectly associated with a security policy. The document, for example, may contain a number of sentences such as:                “John Doe recently moved to Human Resources Department”        “In this meeting, we want to discuss our plans for the third quarter.”        “John Doe can read employee hiring information.”        “Managers can access employee salary information.”        “Jane Doe is not working part-time.”        
From the text, the IT personnel may find two sentences of interest and more directly related to a company security policy: “John Doe can read employee hiring information.” and “Managers can access employee salary information.” The IT personnel may now wish to transform these two sentences into one or more security policies by which the computing platforms of their respective department(s) can perform appropriate actions. The first sentence, “John Doe can read employee hiring information,” presents little problem in transforming the sentence into a security policy because the meaning of the sentence is fairly straightforward. In other words, it is easy to identify all the components (Subject, Action, Resource) that can be directly mapped to certain entities within the computing platforms. For this first sentence, the subject is “John Doe”, the action is “read”, and the resource is “employee hiring information.” Relationships may then be set up within the computing environment giving John Doe read access to the resources containing employee hiring information.
The second sentence, “Managers can access employee salary information,” presents more of a challenge to the IT personnel because the meaning of “access” is too broad. Part of the challenge is that the word “access” cannot be directly mapped to entities within the computing environment. “Access” could mean “read”, “write”, “execute”, and/or other actions. Assumptions may be made to the meaning of the word, e.g., the word “access” may mean “write”. If, however, such a substitution does not make sense in the context of the given sentence, it is a poor assumption and therefore not a correct substitution.
One method of determining a meaning of a word in a particular context is to utilize an ontology. A domain ontology (or domain-specific ontology), for example, models a specific domain, or part of the world. It represents the particular meanings of terms as they apply to that domain. For example the word “card” has many different meanings. An ontology about the domain of poker would likely model the “playing card” meaning of the word, while an ontology about the domain of computer hardware might model the “punch card” or the “video card” meanings.
Domain ontologies may be a useful tool for assisting IT personnel in determining meanings of words such as with the word “access” in the example above. However, IT personnel are still challenged with the task of constructing the ontology.
What is needed therefore is an automated method for constructing a domain specific ontology that can be utilized for interpreting and implementing security policies.